home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000673_janssen@parc.xerox.com _Thu Feb 25 23:34:27 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <janssen@parc.xerox.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA11637; Thu, 25 Feb 93 23:34:27 MET
  4. Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA22721; Thu, 25 Feb 1993 23:51:40 +0100
  6. Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11656>; Thu, 25 Feb 1993 14:51:12 PST
  7. Received: by holmes.parc.xerox.com id <25546>; Thu, 25 Feb 1993 14:51:02 -0800
  8. Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
  9.           via MS.5.6.holmes.parc.xerox.com.sun4_41;
  10.           Thu, 25 Feb 1993 14:50:57 -0800 (PST)
  11. Message-Id: <0fXIpFoB0KGW4v0hoS@holmes.parc.xerox.com>
  12. Date:     Thu, 25 Feb 1993 14:50:57 PST
  13. Sender: Bill Janssen <janssen@parc.xerox.com>
  14. From: Bill Janssen <janssen@parc.xerox.com>
  15. To: marca@ncsa.uiuc.edu (Marc Andreessen)
  16. Subject: Re: xmosaic experience
  17. Cc: WWW-TALK@nxoc01.cern.ch, ebina@ncsa.uiuc.edu
  18. In-Reply-To: <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
  19. References: <EfXGE90B0KGWQv0bZM@holmes.parc.xerox.com>
  20.     <9302252239.AA21530@wintermute.ncsa.uiuc.edu>
  21.  
  22. Relax, Marc.  First off, I really like xmosaic, and am hoping version
  23. 1.0 will be really great!  But secondly, I'm not your customer.  Who
  24. cares what I think?  Thirdly, it *is* a design decision, probably made
  25. for all kinds of reasons I'm not aware of which make it a *good* design
  26. decision.  Fourth, of course I read your explanation.
  27.  
  28. Excerpts from direct: 25-Feb-93 xmosaic experience Marc
  29. Andreessen@ncsa.uiu (2331)
  30.  
  31. > The X Window System has this (to me, fatally flawed) design decision I
  32. > hadn't suspected.  X windows can only be so big.  Up to the size of a
  33. > 16-bit integer, in fact, in pixels.  This is really really bad.  This
  34. > means that the other WWW X browsers (at least Viola and Midas, the
  35. > only two I've been able to get working) will *not* correctly handle
  36. > documents that, when layed out, take up more pixels in height than
  37. > that -- e.g., your RFC.  Go try it on them.  Then look at what X
  38. > Mosaic does, which is lay out as much text as possible in the window
  39. > and then give you convenient automatic inlined hyperlinks to the
  40. > remainder of the text, partitioned into window-sized chunks.  Then
  41. > tell me who's making fatally flawed decisions.
  42.  
  43. Well, since you ask...  If you're displaying text, it really doesn't
  44. matter what the maximum size of a window is, so long as you can get at
  45. least one line on it, right?  As the user scrolls through the text, you
  46. just show different lines, right?  But apparently what you're doing is
  47. turning each document into a giant image of text, and then panning
  48. through that image, which of course runs you into size problems.  This
  49. is an OK idea if you're building something like HyperCard.  But WWW
  50. isn't always like HyperCard, it tends to mix the ``holy scroller'' model
  51. with the ``card shark'' model of hypertext.  So this approach isn't
  52. really suited either to WWW or to the X Window System, so far as I can
  53. see.  (The problem with it on X is that is uses big chunks of window
  54. system resources, typically in one big burst that locks out everything
  55. else on the screen!)  The ``correct'' approach would be more of what
  56. Viola does, which is to use a text widget.  By the way, Viola, the only
  57. other browser I use, *does* in fact use a text widget, and handles my
  58. document just fine.
  59.  
  60. As I said above, maybe I'm missing something?
  61.  
  62. Bill
  63.